Secure and efficient payment processing system

ABSTRACT

A method is provided for carrying out commercial transactions. The method includes the steps of: establishing a transaction processing system on an electronic communications network; establishing an account within the transaction processing system for a corresponding account holder; obtaining from the account holder a session description of acceptable future commercial transactions related to the account; administering commercial transactions carried out via the transaction processing system; and, verifying that administered commercial transactions related to the account meet one or more of the session description.

This application is a continuation of U.S. patent application Ser. No.12/251,853, filed Oct. 15, 2008, which: 1) claims the benefit of U.S.Provisional Application No. 60/980,061, filed Oct. 15, 2007; and 2) is acontinuation-in-part of U.S. patent application Ser. No. 10/011,690,filed Nov. 13, 2001, now U.S. Pat. No. 8,170,954, issued May 1, 2012,which is a continuation-in-part of U.S. patent application Ser. No.09/488,297, filed Jan. 20, 2000, now U.S. Pat. No. 7,742,967, issuedJun. 22, 2010, which claims priority from U.S. Provisional ApplicationNo. 60/157,304, filed Oct. 1, 1999, all of which are incorporated hereinby reference in their entirety.

BACKGROUND OF THE INVENTION

The present invention relates to the art of Internet commerce. It findsparticular application in conjunction with Internet credit and/or debittransactions, and will be described with particular reference thereto.However, it is to be appreciated that the present invention is alsoamenable to other like applications.

Internet commerce, or e-commerce as it is otherwise known, relates tothe buying and selling of products and services over the Internet. Theconvenience of shopping over the Internet has sparked considerableinterest in e-commerce on behalf of both buyers and sellers. Internetsales or like transactions have been typically carried out usingstandard credit and/or debit cards such as Visa®, MasterCard®,Discover®, American Express®, or the like. However, while widely usedfor more traditional face-to-face transactions, use of these standardcards and their associated processing systems in connection withe-commerce presents certain difficulties.

In particular, for example, the standard card transactions typicallyinvolve a relatively high number of intermediaries that are used inprocessing the transaction from an initial purchase request, throughauthentication and authorization, and ultimately to settlement. Inaddition to the actual buyer and seller, the cast involved in ultimatelycompleting the transaction through to settlement typically entailsmember banks including a merchant or acquiring bank and an issuing bank.Often, an Internet processor (e.g., Cybercash), member service provider(MSP), or an independent sales organization (ISO) is also involved.Additionally, third party processors, agent banks, and/or deposit banksare commonly employed. As each intermediary charges a bulk,per-transaction, percentage, or other like fee for its role in handlingthe transaction, the total transaction cost grows with each additionalintermediary employed. Consequently, streamlining transaction processingand elimination of intermediaries beneficially holds transaction costsdown.

Buyer confidence and security are also issues facing Internet commerce.

The fact that e-commerce transactions are not carried out face-to-faceoften creates apprehension in a potential buyer regarding transactions.This apprehension is fueled by uncertainty of the reputation or qualityof the seller with whom they are dealing and the security of theircredit and/or debit card information or other personal information(e.g., address, credit card number, phone number, etc.) typicallysubmitted along with a traditional credit or debit card e-commercetransaction. Additionally, the account holders, sellers and financialinstitutions are concerned about safeguarding against fraudulent orotherwise unauthorized transactions.

For example, once an initial transaction has taken place, wherein acustomer or account holder provides their identification and accountinformation to a seller, the seller, whether operating via the Internetor via a traditional brick and mortar store front, has all theinformation needed to accidentally or fraudulently charge a customer'saccount for goods or services that were not actually purchased.Furthermore, every employee of the seller who comes into contact withthe customer identification and account information has the ability touse that information to initiate fraudulent transactions.

Similarly, sellers or merchants as well as funding sources are concernedthat purchases are made by valid account holders. As outlined above, thefact that someone has access to an account number and other identifyinginformation is not a guarantee that a customer is the authorized accountholder. For example, children can use a parent's credit cards withoutpermission, resulting perhaps in returned merchandise. Credit cards oraccount information can be lost or stolen and used by unauthorizedpersonnel to make purchases resulting in one of the account holder, themerchant, or the funding source suffering a theft loss. Additionally,data entry errors and the like can result in multiple charges for asingle purchase.

Yet another issue is convenience for the buyer. As more and moretransactions are carried out online, the repeated typing of requiredtransaction information such as, for example, name, credit or debitaccount information, and/or shipping address information becomes tediousand aggravating. There is a need to identify a valid account holderwhich identification is recognized and subsisting for a plurality oftransactions, or a limited period of time, or for a limited purchasingamount. Furthermore, writing checks to settle accounts is a tedious andoften overlooked task resulting in delayed payment for sellers and latecharges for consumers.

The present invention contemplates a new and improved transactionprocessing system and technique for carrying out credit and/or debittransactions over the Internet that overcomes the above-referencedproblems and others.

BRIEF SUMMARY OF THE INVENTION

In accordance with one aspect of the present invention, a method forcarrying out commercial transactions is provided. The method includesestablishing a transaction processing system on an electroniccommunications network, and establishing an account within thetransaction processing system for a corresponding account holder. If thecorresponding account holder is a true account holder, then either thesystem, or the holder, may selectively set a window of acceptable,authenticated transactions, wherein the window is comprised of either adollar amount, a timeout period, or a maximum number of transactions.One or more descriptions of acceptable future commercial transactionsrelated to the account are obtained from the account holder. Commercialtransactions carried out via the transaction processing system areadministered, and it is verified that administered commercialtransactions related to the account meet one or more of the descriptionsobtained.

In accordance with another aspect of the present invention, a method ofprocessing commercial transactions is carried out over the Internetbetween account holders and participating merchants. The method includesestablishing account privileges for each account holder's account. Theprivileges defining boundaries outside of which transactions are not tobe authorized. A buyer's purchase request is received from aparticipating merchant indicating that the buyer desires to carry out atransaction with the merchant in which the buyer is purchasing one ormore selected items from the merchant. The buyer is authenticated as anaccount holder, and transaction details are received from theparticipating merchant. The transaction details including a cost for theselected items. Authorizing completion of the transaction occurs whenthe transaction details do not violate established account privilegesand the account holder's account is full enough to cover the cost.

One advantage of the present invention is found in an automated accountsettlement aspect that includes reasonableness checking of submittedcharges.

Another advantage of the present invention resides in immediate andautomatic notification generation when out of tolerance charges aresubmitted.

Another advantage of the present invention is that buyers and sellersare protected from fraudulent or otherwise unauthorized transactions.

Yet another advantage of the present invention is that transaction costsare reduced to the extent that streamlined processing reducesintermediaries that would otherwise contribute to the transaction costs.

Still further advantages and benefits of the present invention willbecome apparent to those of ordinary skill in the art upon reading andunderstanding the following detailed description of the preferredembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may take form in various components and arrangements ofcomponents, and in various steps and arrangements of steps. The drawingsare only for purposes of illustrating preferred embodiments and are notto be construed as limiting the invention.

FIG. 1 is a flow chart showing a high level overview of an onlinecredit/debit transaction processing system in accordance with aspects ofthe present invention.

FIG. 2 is a diagrammatic illustration showing Internet connectedparticipants in an online credit/debit transaction processing system inaccordance with aspects of the present invention.

FIG. 3 is a flow chart showing a process for registering sellers forparticipation in an online credit/debit transaction processing system inaccordance with aspects of the present invention.

FIG. 4 is a flow chart showing a process for registering account holdersfor participation in an online credit/debit transaction processingsystem in accordance with aspects of the present invention.

FIG. 5 is a diagrammatic illustration showing a credit token for use inconnection with an online credit/debit transaction processing system inaccordance with aspects of the present invention.

FIGS. 6A and 6B are flow charts showing an online shopping experienceand related processing in accordance with aspects of the presentinvention with pre-shopping authentication and post-shoppingauthentication, respectively.

FIG. 6C is a flow chart showing implementation of additional securitymeasures invoked by certain delivery destination conditions which areselected in connection with an online credit/debit transactionprocessing system in accordance with aspects of the present invention.

FIG. 7 is a flow chart showing a settlement process of an onlinecredit/debit transaction processing system in accordance with aspects ofthe present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

With reference to FIG. 1, a central transaction coordinator 10administers a number of different yet inter-dependent processes in acommercial Internet credit/debit transaction processing system A. Theprocesses administered by the coordinator 10 include: (i) a sellerregistration process 100 wherein merchants or sellers are signed up forparticipation in the transaction processing system A; (ii) an accountholder registration processes 200 wherein buyers or consumers are signedup as account holders for participation in the transaction processingsystem A; (iii) an online shopping process 300 wherein buyers orconsumers engage in online commercial transactions with merchants orsellers; and, (iv) a settlement process 400 wherein completed commercialtransactions are confirmed and settlement information forwarded directlyto a funding source for billing and payment processing. In addition, thecoordinator 10 itself optionally acts as the funding source. However, inthe interest of simplicity and clarity, in the following description,the discussion is directed to embodiments employing a third partyfunding source.

With further reference to FIG. 2, in a preferred embodiment, thecoordinator 10 maintains a presence on the Internet 50 or other likeonline network via a server 12. A merchant or seller 20 also maintains apresence on the Internet 50 via a server 22. A buyer or account holder30 gains access to the seller 20 and/or the coordinator 10 over theInternet 50 using a computer 32 with an appropriate web browser or otherlike software running thereon. Of course, the transaction processingsystem A is preferably administered to multiple similarly situatedsellers 20 and buyers 30. However, in the interest of simplicity herein,only a one of each is shown in FIG. 2. Additionally, a funding source 40maintains a presence on the Internet 50 via a server 42. The fundingsource 40 extends credit for credit accounts or holds deposits for debitaccounts created on behalf of account holders participating in thetransaction processing system A. Moreover, it is to be appreciated thatthe security of the transaction processing system A is further enhancedby encrypting, with known encryption techniques, communications relayedor otherwise transmitted over the Internet 50.

With further reference to FIG. 3, in the seller registration process100, an interested merchant or seller 20, preferably doing business onthe Internet 50 via their server 22, is registered for participation inthe transaction processing system A administered by the transactioncoordinator 10. The seller registration process 100 begins with thecoordinator 10 receiving seller information 102 (e.g., financialinformation, physical address, category of goods or services sold,Internet address, e-mail address, etc.) from the seller 20. Online orover the Internet 50, this is optionally accomplished by receiving theseller information 102, perhaps encrypted, via the coordinator's server12. Using the received seller information 102, the worthiness of theseller 20 for participation in the transaction processing system A isevaluated.

Preferably, a verification program 110 is applied to evaluate the seller20 based on the seller information 102 received by the coordinator 10.The verification program 110, optionally running on the coordinator'sserver 12, is carried out using a predetermined or otherwise selectedalgorithm that acts on quantifiable values representing the sellerinformation 102. In this manner, the seller's credit worthiness isdetermined and/or the seller's reliability and reputation for customerservice and sound business practice is determined using objective,subjective, or a combination of objective and subjective criteria.Accordingly, the coordinator 10 ensures that the seller 20 is able tomeet potential obligations. Moreover, account holders 30 participatingin the transaction processing system A are reassured that they arepatronizing high quality merchants or sellers with strong customersatisfaction guarantees.

In response to the evaluation, at decision step 120, the coordinator 10decides whether or not the interested seller 20 is declined or approvedfor participation. If declined, a notification 122 is sent to theinterested seller 20 and the seller registration process 100 ends. Ifapproved, the coordinator 10 forwards a seller agreement 124 to theseller 20. Online or over the Internet 50, the seller agreement 124 isoptionally forwarded from the coordinator's server 12 to the seller'sserver 22. The seller agreement 124 outlines the rights andresponsibilities or duties of the seller 20 with respect to theirparticipation in the transaction processing system A. After the seller20 physically signs, electronically signs, or otherwise executes theseller agreement 124, it is returned to the coordinator 10, perhapsthrough the coordinator's server 12. Upon receipt of the executed selleragreement 124 a, the coordinator 10 creates and maintains a record ofthe seller information 102, the seller's approval, the seller agreement124, etc. Preferably, the record is electronically created andmaintained in a coordinator's database 14 which is accessible by thecoordinator 10, and optionally, the funding source 40.

Preferably, upon acceptance of the executed seller agreement 124 a, thecoordinator 10 forwards to the seller 20 a transaction object 126 whichplaces a link on the seller's online shopping check-out page orotherwise runs on the seller's server 22. The object or link operates tointegrate the transaction processing system A into, or otherwise allowsthe processing system A to be accessed through, the seller's onlineshopping system or Internet shopping web page or pages. Optionally, thecoordinator 10 installs the object on the seller's server 22.Accordingly, account holders 30 shopping online or over the Internet 50can access the object (e.g., by clicking the link on seller's check-outweb page) and be automatically routed to the coordinator 10 forauthentication and/or authorization. In this manner then, merchants orsellers 20 become registered for participation in the transactionprocessing system A.

With further reference to FIG. 4, in the account holder registrationprocess 200, registration of a buyer or consumer to become an accountholder 30 begins with a visit by the buyer to the coordinator 10.Optionally, over the Internet, the interested buyer or consumer, usingan appropriate web browser, accesses an account holder registration pagewhich is made available via the coordinator's sever 12. As the accountholder registration process 200 continues, account holder registrationdata 202 (e.g., name, address, length at residence, own or rentresidence, e-mail address, home phone number, work phone number, socialsecurity number, date of birth, mother's maiden name, employer, income,employment status, etc.) is collected or otherwise obtained by thecoordinator 10 from the buyer or the potential new account holder 30 whois making application for participation in the transaction processingsystem A. Prior to accepting the consumer or buyer as a new accountholder 30, their credit worthiness is evaluated.

Preferably, the coordinator 10 passes relevant account holderregistration data 202 to the funding source 40. The relevant accountholder registration data 202 is then analyzed for credit worthiness.Optionally, the data is analyzed by the funding source's own creditapproval system, or it is passed on to one or more credit bureaus 210for analysis. The analysis preferably includes the application of knowncredit approval techniques and algorithms which determine creditworthiness. Ultimately, credit approval data 212 (e.g., approval ordenial, amount of credit, risk, etc.) is routed back to the coordinator10 through the funding source 40.

Upon receipt of the credit approval data 212, the coordinator 10decides, at decision step 220, if the potential new account holder 30 isworthy of participation in the transaction processing system A. Then thecoordinator 10 notifies the potential new account holder 30 of thecredit decision. That is to say, if credit is declined, acredit-declined message 222 is communicated to the potential accountholder 30. On the other hand, if credit is approved, approvalinformation 224 (e.g., the annual percentage rate, credit limit, etc.)is communicated to the potential new account holder 30 for acceptance.In a preferred embodiment, the credit approval or denial is communicatedto an online potential new account holder 30 accessing the coordinatorover the Internet 50 by displaying an appropriate web page from thecoordinator's server 12 to the potential new account holder 30.Alternately, the credit approval or denial is communicated via e-mail tothe potential new account holder's designated e-mail address previouslyobtained along with the account holder registration data 202. In anyevent, optionally, at this time, the potential new account holder 30 isadvanced an initial, albeit preferably limited, line of credit andtemporary password enabling him to immediately shop online at aregistered seller 20 using the transaction processing system Aadministered by the transaction coordinator 10.

If approved and account holder status is still desired, along with anindication of acceptance, the account holder 30 supplies the coordinator10 with additional account creation data 226 including a secret personalidentification number (PIN) and the answers to a number of designated orotherwise selected security questions. The security questions arepreferably questions to which only the account holder 30 is likely toknow the answers (e.g., the account holder's first car, the name of theaccount holder's dog, the maiden name of the account holder's mother,etc.). Upon acceptance, the coordinator 10 creates and maintains arecord for the account holder 30, preferably in electronic format on thecoordinator's database 14. The account holder record includes theaccount holder registration data 202, credit approval data 212, approvalinformation 224, acceptance, and the additional account creation data226. In addition, a corresponding credit account is created with thefunding source 40. Optionally, the account holder 30 may designate oneor more existing credit or debit accounts for use in connection thetransaction processing system A, in which case information pertainingthereto is collected and maintained in the account holder record.

The account holder record may also contain information or data relatingto account privileges. In a preferred embodiment the account holder 30has the option to customize or modify their account privileges. Theaccount privileges are customized by the account holder 30, for example,by accessing the coordinator's server 12 over the Internet 50. Forsecurity purposes, the account holder is optionally authenticate assuch, preferably, using the below described authentication procedure,prior to permitting any account modifications. However, at initialaccount creation, the below described authentication procedure is notemployed. The account privileges are optionally set by the accountholder 30 to limit the use of the account holder's account in thetransaction processing system A. That is to say, the set accountprivileges may restrict the account so that purchases thereon are notauthorized for specified participating merchants or sellers 20, so thatautomatically recurring transactions carried out absent the directparticipation of the account holder 30 are not authorized, so thatsingle purchases over a certain price limit are not authorized, so thataggregate per day purchases are limited to a desired level, and thelike.

By manipulating the account privileges, the account holder 30 mayselectively set up virtual purchase orders and control or limit thetransaction authorization given by the coordinator 10. For example, theaccount privileges portion of the account holder record preferablyidentifies those registered merchants or sellers 20 for which theaccount holder 30 may desire or intend to do business and hence forwhich transactions on the account are to be authorized. Optionally, toadd and delete registered sellers 20 from the list, the coordinator 10provides selection boxes. For example, the account holder 30,interacting with the server 12 of the coordinator 10, to provide theadditional account creation data 226, may choose to globally authorizeor globally de-authorize all the registered sellers. Then the accountholder 30 may switch the authorization state of individual sellers. Forexample, where the account holder globally authorizes all availableregistered sellers 20, the account holder 30 may then de-authorizeparticular individual sellers 20. For example, the account holder 30de-selects merchants the account holder 30 does not intend to dobusiness with, thereby deleting them from the authorized merchant list.Conversely, where the account holder 30 globally de-authorizes allavailable registered sellers 20, the account holder 30 may then selectparticular individual sellers, thereby adding them to the authorizedmerchant list. Other global restrictions optionally include, restrictingauthorization for single purchases exceeding a selected amount, or foraggregate purchases in a selected time period.

An account holder 30 selectively sets up a virtual purchase order viathe account privileges by pre-defining transaction boundaries for anidentified seller 20. The boundaries optionally include a limit on thetransaction amount, a limit on the number of transactions forautomatically or otherwise repeating transactions, a purchase orderexpiration data after which repeating transactions are not longer to beauthorized, a frequency (e.g., weekly, monthly, etc.) at which repeatingtransactions are to be authorized, ranges and/or tolerances within whichtransaction amounts and/or dates are to fall, etc. In this manner, theauthorization of anticipated transactions is controlled by the accountholder 30 prior to the execution of the transactions. Consequently,accidental and/or fraudulent transactions are frustrated. Additionally,insomuch as authorization will be denied for transactions not inconformity with the boundaries of the virtual purchase order prior tocharging the designated account, charge backs, billing disputes and thelike will be reduced.

In any event, at the initial account creation, the coordinator 10 alsoassigns the account holder 30 an associated user identity which isunique to the account holder 30 and becomes part of the account holder'srecord (e.g., a self-selected user name, or an otherwise assignedalpha-numeric designation), and optionally, a corresponding credit token230 (see FIG. 5) is issued to the account holder 30. The credit token230 periodically (e.g., every 60 seconds) generates a non-predictablealpha-numeric code (preferably 6 characters in length) using apredetermined or otherwise selected algorithm. The algorithm used ingenerating the periodically changing non-predictable alpha-numeric codeis preferably a function of an initial seed value and a time valueobtained from an internal clock. The credit token 230 renders the codeon an incorporated liquid crystal display (LCD) readout 232 or otherlike human-viewable display. Additionally, the credit token 230 providesan indicator as to the duration of the displayed code's validity (i.e.,the time remaining before generation of the next non-predictable code).Accordingly, every period, the credit token 230 generates a dynamicallychanging non-predictable alpha-numeric code which (with the exception ofthe coordinator 10) is only available to the account holder 30 inpossession of the credit token 230.

For each unique user identity, the coordinator 10 also independentlygenerates a periodically changing non-predictable alpha-numeric codewhich is synchronized with and the same as the token generated code forthe corresponding account holder 30 having that user identity. Theindependently generated and synchronized code is maintained with thecorresponding account holder's record. Preferably, the coordinator 10generates the synchronized code by running software which uses (i) analgorithm and (ii) an initial seed value which are both identical tothat used by the corresponding token 230 and (iii) a time value from aclock which is synchronized with the token's internal clock. In thismanner then, the alpha-numeric code from an account holder's credittoken 230 and the independently generated alpha-numeric code maintainedwith the account holder's record are the same at any given time.

In an alternate preferred embodiment, the token 230 stores a defined setof discrete random or quasi-random numbers which are pre-loaded onto thetoken 230 at the time of the token's manufacture or programming. Thesenumbers are preferably generated by an external system (e.g., a computersystem or other random number generating device). The external systemthen delivers the number set to the token 230 for storage in the token'sinternal memory. Likewise, the same number set is delivered to andmaintained with the corresponding account holder record.

Generating the numbers on an external system relieves the token 230 of asignificant amount of computational overhead. By reducing thecomputational overhead, energy savings are realized that enable thetoken to use smaller, less powerful energy sources.

The random numbers are dispensed by the token 230 to a user by pressinga button on the token 230 or otherwise signaling the token 230.Optionally, the token 230 may need to be activated by using the secretPIN that was assigned to, or chosen by, the account holder 30 at thetime of registration. In any event, a dispensed number from the token230 may then be cross referenced against those in the correspondingaccount holder record. In this way, authentication can be carried out.

In an alternate embodiment, a potential new account holder 30 maycontact the funding source 40 directly for registration to participatein the transaction processing system A. In this case, the funding sourcecarries out substantially the same account holder registration process200 and forwards the account holder record to the coordinator 10.

With further reference to FIGS. 6A and 6B, in a preferred embodiment, anonline or Internet shopping experience or process 300 begins with anaccount holder 30 contacting the coordinator 10 (e.g., accessing thecoordinator's online or Internet shopping portal using an appropriateweb browser) or otherwise requesting a web page from or linking to thecoordinator's server 12. At this juncture, the account holder 30 isgiven the option to pre-authenticate their identity prior to engaging inany particular commercial transactions with the participating merchantsor sellers. Authentication is preferably accomplished by the coordinator10 collecting from the account holder 30 authentication data 302 havingone or more elements including the account holder's user identity, PIN,and/or token generated alpha-numeric code. Optionally, one or moreelements of the authentication data 302 are entered manually by theaccount holder 30. Alternately, one or more of the elements are storedor otherwise maintained on the computer 32 being employed by the accountholder 30 to access the coordinator's server 12 such that they areautomatically entered where appropriate. For example, with regard to thenon-predictable alpha-numeric code, rather than having a separatephysical token 230, the “token” is optionally an object running on theaccount holder's computer 32 which enters or displays the alpha-numericcode when accessed. Alternately, a separate physical token 230optionally includes an interface 234 (see FIG. 5) through which it isconnected to the account holder's computer such that the token generatedalpha-numeric code is read directly from the token 230 without manualentry.

In any event, the coordinator 10 runs the authentication data 302through an authentication process 310 which compares the entered orotherwise collected authentication data 302 with the corresponding datain the account holder record having the same user identity as thatincluded with the authentication data 302. The coordinator 10 thendetermines, at decision step 320, whether or not the alleged accountholder 30 is an authentic account holder previously registered using theaccount holder registration process 200. Of course, where the useridentity included with the authentication data 302 does not have acorresponding account holder record or is otherwise invalid, theauthentication is denied or fails and the alleged account holder 30and/or involved seller 20 is sent a denial notification 322.Additionally, where the authentication data 302 and corresponding datain the account holder record having the same user identity do not match,the authentication is also denied or fails and the alleged accountholder 30 and/or involved seller 20 is again sent the denialnotification 322. Only when there is an identical match between theauthentication data 302 and the account holder record does the accessingaccount holder 30 become authenticated and/or positively identified asthe true account holder having the corresponding user identity.

In one preferred embodiment, the authentication or positiveidentification is carried out, e.g., as described in the previouslyreferenced U.S. Pat. Nos. 5,168,520 and 4,720,860. Alternately, otherauthentication methods or procedures may be employed that positivelyidentify the account holder 30, e.g., challenge response, quick logmode, other one or more factor authentication methods (such as a staticuser name and password or PIN), smart cards, the aforementioned numberdispenser, biometric authentication (such as fingerprint recognition orretinal scanners), etc. These authentication techniques ensure that thecoordinator 10 is able to independently make a positive identificationof the account holders 30.

With particular reference now to FIG. 6A, next, the account holder 30requests, or the coordinator's server 12 otherwise displays, a web pageor the like with a shopping directory 330 listing participatingmerchants or sellers 20 that are registered with the transactionprocessing system A system administered by the coordinator 10. Theaccount holder 30 is then free to select the participating seller 20 ofhis choice and shop as a pre-authenticated account holder 30 a.

With particular reference now to FIG. 6B, alternately, the accountholder 30 accesses the seller's online store or Internet shopping sitedirectly from the seller's server 22 and shopping is carried out absentpre-authentication. At the seller's site, the buyer or account holder 30selects items 340 of goods and/or services which are desired forpurchasing. Preferably, these goods or services are then placed into avirtual shopping cart 342. If more shopping is desired, the processloops back to product selection and other like shopping web pages madeavailable from the seller's server 22. On the other hand, if shopping iscomplete, the process continues on to check-out 350. When the buyer oraccount holder 30 accesses the transaction object 126 or link previouslyestablished on the participating merchant's or seller's check-out page350, the buyer or account holder 30 is routed to the coordinator 10along with a purchase request 352 indicating the buyer desires to carryout a commercial transaction with the referring participating seller 20.Preferably, the transaction in question includes the buyer or accountholder 30 purchasing one or more selected items from the participatingmerchant or seller 20.

If not pre-authenticated, when the buyer or account holder 30 is routedto the coordinator 10, they are presented with an authentication pagefrom the coordinator's server 12. At this point, using the sameauthentication procedure 310 as used in pre-authentication, the buyer isauthenticating and/or positively identified as an account holder 30having a unique user identity. If pre-authenticated, the account holder30 bypasses this authentication step.

In any event, provided authentication is complete and successful, thecoordinator 10, at process step 360, establishes transaction fulfillmentdata 362. The transaction fulfillment data 362 identifies informationwhich is used by the participating seller 20 to fulfill theirobligation(s) to the account holder 30 for the commercial transaction inwhich they are currently engaged. For example, the transactionfulfillment data 362 preferably includes a delivery destination for theitems selected for purchase in the transaction. For physical goods, thedelivery destination may be a shipping address, and for downloadedcontent, downloaded software, digital goods or services, and other likeitems, the delivery destination may be an e-mail address or the accountholder's networked computer 32.

With continued reference to FIG. 6B, an alternative embodiment is shownwhich permits an account holder to designate a authentication windowpermitting the authentication of multiple transactions in the windowwithout having to repeatedly perform the authentication process 310. Inother words, as opposed to requiring the use of a unique number/code toidentify a particular transaction, a session based authenticationidentifies an authenticated user, i.e. a true account holder, throughoutthe window defined by preselected threshold parameters. For example, ifthe account holder knows that he/she will occasionally perform a groupof transactions, and it is desired not to have to go through theauthentication process for each transaction in the group, then theaccount holder can preset the system to accept a prior authentication ina manner to bypass the authentication process 310 so that the grouptransactions are not unique individually, but rather the entire sessioncan authenticate multiple transactions related by the sessiondefinition. More particularly, a session can be identified by a presetnumber of transactions, a time limited window where the priorauthentication is acceptable, or to a limited dollar amount in which thecumulative transactions must fall within.

As can be seen with reference to FIG. 6B, if a true account is onewherein a prior authentication code can be accepted 502, then the presetparameters identifying an authenticated session 504 need to be checked.If the parameters have not timed out, then the prior authenticated trueaccount holder may immediately have the transaction process directed toestablishing the fulfillment data 360, but if the prior authenticationsession data has expired, as in the time window parameter, or has beenused up, as in the dollar amount or number of transactions parameterdata, then the authentication process 310 must be re-initiated forauthenticating the desired transaction.

The foregoing alternative embodiment of session based authenticationavoids the disadvantages of requiring a unique authentication processfor each individual transaction of an account holder, when the accountholder knows those transactions in a predetermined session should all beauthenticated without a problem. Associating the transactions in amatter in an authenticated session provides greater efficiency in theauthentication process per transaction and relieves the account holderof the task of having to repeatedly go through the authenticationprocess. Several alternatives can also be envisioned as the selectedthresholds for defining a time out session beyond the foregoing dollar,time or transaction number or windows. For example, the number oftransactions may be those that are completed at a particularmerchant/URL at which the transactions are occurring, or could be atmultiple merchants/URL locations. The dollar amount could be related tothe time window to accommodate relatively smaller purchases overextended time, or only a few high dollar purchases in a smaller window.It is important within the present embodiment to recognize that thesession is intended to accomplish multiple transactions, all of whichcan be authenticated by a single authentication process and to avoid theinconvenience of having to assign a unique transaction code to eachtransaction in a session comprised of a plurality of transactions.

With further reference to FIG. 6C, in a preferred embodiment, previouslydesignated (e.g., at account creation) default delivery destinations forthe various types of goods or services are maintained in the accountholder's record. As a rule, the coordinator 10 uses these defaultdesignations in establishing the transaction fulfillment data 362.However, at a destination selection web page 364 presented to theaccount holder 30 by the coordinator 10, the account holder 30 mayoptionally designate, via a selection response 366, an alternatedestination as the delivery destination.

In a preferred embodiment, if the alternate destination differs from thedefault destination or if the destination is a direct download to thebuyer's or account holder's computer 32, an additional securityprecaution is invoked. More specifically, the coordinator 10 transmitsone or more of the previously answered security questions 226 a (i.e.,the security questions to which the account holder 30 originallyprovided answers in connection with the submitted additional accountcreation data 226) to the buyer or account holder 30. The coordinator 10then receives from the buyer or account holder 30 an answer 226 b inresponse to each security question. The coordinator 10 then determines,at decision step 370, if the answers 226 b are correct. As shown atprocess step 372, only when the newly received responses match thepreviously given answers in the account holder's record is the alternateor download destination included in the established transactionfulfillment data 362. Otherwise, as shown at process step 374, thealternate or download destination is rejected. Optionally, approvedalternate destinations may also be stored in an account holder addressbook maintained with the account holder's record for convenient futureaccess and use by the account holder 30.

Optionally, the delivery destination is a non-identifying destinationsuch that anonymity of the account holder 30 is maintained with respectto the participating merchant or seller 20. For example, thenon-identifying destination may be a post office box, or other neutralthird party from which delivered goods are obtained by the accountholder 30. Regardless of the delivery destination, once established, thetransaction fulfillment data 362 is communicated by the coordinator 10,preferably online or over the Internet 50, to the participating seller20, and the account holder 30 is routed back the participating seller 20where they are optionally presented a shipping choice 380 includingchoice of shipping carrier (e.g., regular U.S. mail, Federal Express,UPS, etc.) and/or preferred shipping time (e.g., 1 month, 1 week, ornext day delivery).

After the account holder 30 has made their selection 382, if any, withregard to shipping carrier and/or preferred shipping time, thetransaction details 384 are transmitted from the seller 20 to thecoordinator 10 where they are received for authorization processing 390.The transaction details 384 preferably include the total cost (with taxand shipping) for the selected items being purchased in the transaction.Additionally, the transaction details 384 identify the participatingmerchant or seller 20 and account holder 30 engaged in the transaction.

The authorization process 390 preferably has two parts, one is basedupon the account holder's account having an amount of available creditor funds sufficient to cover the total cost of the transaction, theother is based upon the transaction details 384 not violating thelimitations and/or restrictions set forth in the account privileges ofthe account holder record. If the transaction details 384 are not withinthe boundaries of a virtual purchase order and/or other globalrestrictions that may have been set up by the account holder 30, thenauthorization is denied. Otherwise, the authorization process 390determines the availability of funds or credit. Optionally, if theaccount privileges have been violated in any way, a notification orwarning regarding the same is forwarded to the account holder 30,preferably, via e-mail. In response to the warning, the account holder30 may be given the option to override the denial of authorization, inwhich case authorization will be given.

Alternately, the account is optionally a debit account such thatauthorization is based upon the debit account having a sufficient amountof funds on deposit to cover the total cost of the transaction, or theaccount is a credit account such that authorization is based upon thecredit account having a sufficient amount of available credit to coverthe total cost of the transaction. In either case, when a sufficientamount of funds or credit is available to cover the total cost of thetransaction, completion of the transaction is authorized, if notauthorization is denied.

Optionally, the status of the account holder's account (credit or debit)is maintained along with the account holder's record in thecoordinator's database 14 such that the coordinator 10 may directlyauthorize transactions. Alternately, the transaction details 384 arepassed along to the funding source 40 which then authorizes thetransactions. In either case, upon determining authorization (in theaffirmative or in the negative), a corresponding authorization code 392is established for the transaction. Preferably, the authorization code392 along with the authorization result and the correspondingtransaction details 384 are maintained in a transaction record,optionally, stored electronically in the coordinator's database 14.Additionally, an indication of the authorization outcome and theauthorization code 392 are communicated to the participating merchant orseller 20 and account hold 30 which then act accordingly.

With further reference to FIG. 7, the settlement process 400 forcompleted commercial transactions begins with the coordinator 10collecting or otherwise obtaining settlement information 402 from theseller 30. Preferably, the settlement process 400 occurs periodically,e.g., daily, weekly, etc. Alternately, the settlement information 402 isobtained by the seller 20 routing settlement information 402 to thecoordinator 10 or by the coordinator 10 automatically extractingsettlement information 402 from the seller 20. For example, with regardto the automatic extraction of settlement information, when a seller'sdelivery process is executed thereby delivering purchased goods orservices to the account holder 30, a seller's inventory database 24 (seeFIG. 2) or other such seller database is accordingly updated to indicatedelivery and completion of the particular transaction. In the settlementprocedure 400 then, settlement information 402 corresponding to thosetransactions indicated in the seller's database 24 as having beencompleted is automatically retrieved by the coordinator 10 from theseller's database 24.

The settlement information 402 indicates that the seller 20 hasfulfilled his obligations to an account holder 30 in connection with aparticular authorized commercial transaction. The obtained settlementinformation 402 preferably includes the authorization code 392 and thecorresponding transaction details 384 for the transaction in question.The coordinator 10 then matches the settlement information 402 to thecorresponding transaction record having the same authorization code 392to confirm or otherwise validate and approve settlement when thetransaction details 384 in the settlement information 402 aresubstantially the same as the transaction details 384 in the transactionrecord. In particular, the total cost from the transaction details 384reported in the settlement information 402 is optionally permitted tovary within a given tolerance from the total cost contained in thetransaction details 384 of the transaction record. In the cases wherethere is an insufficient match, rejected settlement information 402 a isreturned to the seller 20.

In a preferred embodiment, periodically (e.g., at the end of each day),the coordinator 10 communicates confirmed settlement information 402 bdirectly to the funding source 40, preferably over the Internet 50 orother online network. In turn, the funding source 40 acts accordingly onthe confirmed settlement information 402 b, e.g., sending bills 410 tothe appropriate account holders 30 and reimbursing the appropriatemerchants or sellers 20 with payment 420 using known billing and paymentprocessing procedures and methods. As the settlement information 402 hasalready been confirmed by the coordinator 10, optionally, the fundingsource 40 does not employ independent confirmation of the settlementinformation 402 and thus may act on the confirmed settlement information402 b more readily without additional procedures for validating it.

In this manner, transactions conducted in the transaction processingsystem A are streamlined as compared to traditional transactionprocessing systems. In the traditional system, buyers or account holdersmake purchases using a traditional credit card. The credit card number,expiration date, and accompanying personal information is then forwardedto numerous different intermediaries in an attempt to positivelyidentify and/or authenticate the buyer as the credit card owner. Stillfurther intermediaries are often employed to then authorize a particulartransaction and the information is again routed to these additionalintermediaries. As a result this system is inherently inefficient. Inthe transaction processing system A described herein, by providingpositive user identification and/or authentication at check-out throughthe coordinator 10 and by integrating the authentication andauthorization procedures 310 and 390, respectively, with the coordinator10, desirable efficiencies are gained insomuch as the inefficientmerchant banking system and the numerous intermediaries are avoided onboth the purchase side and the settlement side.

The invention has been described with reference to the preferredembodiments. Obviously, modifications and alterations will occur toothers upon reading and understanding the preceding detaileddescription. For example, the transaction processing system A is equallyapplicable to and adept at handling face-to-face transactions, telephonetransactions, and the like, as it is at handling Internet transactions.It is intended that the invention be construed as including all suchmodifications and alterations insofar as they come within the scope ofthe appended claims or the equivalents thereof.

Having thus described the preferred embodiment(s), the invention is nowclaimed to be:
 1. A method for processing transactions carried out overthe Internet between account holders and merchants, said systemcomprising: registering one or more account holders, said registeringgenerating account holder records for the account holders registered;receiving a purchase request of a buyer from a merchant over theInternet indicating that the buyer desires to carry out a transactionwith the merchant, said transaction including the buyer purchasing oneor more selected items; receiving over the Internet transaction detailsfrom the merchant, said transaction details including a cost for thepurchase; comparing a provided authentication data to data in theaccount holder records, said provided authentication data including atleast one of a user name, a password, a personal identification numberand a dynamically changing non-predictable code, wherein the buyer isidentified as an account holder when there is a sufficient matchresulting from the comparison, and the buyer is not identified as anaccount holder when there is no sufficient match resulting from thecomparison; authorizing completion of the transaction when the buyer isidentified as an account holder and establishing an authorizationdetermination for the transaction in accordance with said authorizing,wherein said authorizing includes: transmitting the transaction detailsover the Internet to a funding source which determines if the identifiedaccount holder has sufficient funds on deposit with the funding sourceto cover the cost of the purchase; and, receiving the authorizationdetermination from the funding source over the Internet; and,communicating over the Internet the authorization determination for thetransaction to the participating entity.